This application relates to data processing systems having an intercept library configured to intercept calls to an application programming interface (API) so as to allow actions to be performed in response to those calls without requiring modification of the application or API itself. The application also relates to an improved mechanism for filtering received messages suitable for use with a data processing system having such an intercept library.
Generally, applications supported by an operating system will be configured to interact with the operating system and other user-level entities by means of software libraries that are configured to provide an application programming interface (API) to the application. Thus, an API defines a standard set of calls by means of which an application can interact with its software environment. For example, a socket library providing a Berkeley sockets API is typically offered by an operating system in order to facilitate high-level communications to and from an application.
Over time, many APIs have become standardised such that an application installed at an operating system will expect to be able to interact with its environment using a set of standard APIs. This presents the problem that the set of functions provided by an API cannot be modified without breaking the API or requiring that the application is itself modified to utilise a modified set of functions. Thus, whilst standardised APIs have the advantage of widespread compatibility with applications, they make it difficult to accommodate changes to the underlying structure of a data processing system—changes, for example, that might provide significant performance improvements were an API able to present an appropriate set of functions.
This problem is well illustrated by a Berkeley socket library which does not provide a mechanism by which received messages can be filtered by an application prior to the receive processing of those messages at the network protocol stack. Conventionally, in order to avoid received messages having to traverse the network protocol stack prior to filtering, one or both of the application and the socket library would have to be modified in order to accommodate a modified receive mechanism, or filtering would have to be performed at the kernel.
The Solarflare OpenOnload user level network stack uses intercept libraries in order to perform certain fixed socket-related functions, but these intercept libraries do not provide the flexibility to allow the behaviour of an application through an API to be readily modified without requiring modification to the application or API. The Solarflare OpenOnload intercept libraries do not, for example, allow filtering of received messages to be performed at the receive queue without modification to the application and socket API.
There is therefore a need for mechanisms by which an application can take advantage of modifications to the operation of its data processing system without requiring modification of the application itself or one or more APIs defining its software environment. In particular there is a need for mechanisms by which the filtering of messages received for an application can be performed without those messages having to first traverse the network protocol stack and without requiring modification of the application itself or the sockets API.